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TASK: To enable an IP network provider offering an Internet telephony service to provide billing 
based on guaranteed call quality. 

SOLUTION: Packet loss per unit time of each RTP session is observed at a gateway device 
disposed at the boundary between a provider's IP network and a user access network, and if a 
threshold value (which depends on the codec used) held by the gateway device or given by a call 
processing server is exceeded, the call processing server is notified, whereupon the call processing 
server reacts by either making the call (or the user) using the RTP session in question non-billable 
or forcing disconnection, so that a time-based charge is not generated when voice quality has 
deteriorated. The threshold value may be determined empirically by making an objective 
measurement of voice quality (as typified by R-value, PSQM, etc.) and correlating the state of 
deterioration of voice quality due to packet loss rate with the codec and packetizing period. 
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Claims 

1 . A method of guaranteeing voice quality in an Internet telephony service, characterised in 
that in the case of a provider such as an ISP or an ASP who arranges, on the provider's IP 
network that uses an Internet protocol, call processing servers such as for example SIP proxy 
servers or gatekeeper servers having a function for converting between the user ID and the IP 
address of a call processing message in an Internet telephony protocol such as for example SIP 
or ITU-T H.323, and who offers an Internet telephony service to users who utilize a protocol 
such as IP or IP over PPP to connect to the provider's IP network: 

when such a provider implements billing by calling time, the provider guarantees a 
certain minimum voice quality for each call, and if call quality falls below standard, the 
provider stops billing or forces disconnection, from the network side, of the call in question. 

2. The method of guaranteeing voice quality in an Internet telephony service as set forth in 
Claim 1, wherein gateway devices arranged at connection points in all access modes between 
said provider's IP network and either a user IP network or an IP over PPP terminal, monitor - 
under the control of a call processing server - packet flows from the provider's IP network to 
users during RTP sessions specified by source and destination IP addresses and source and 
destination port numbers, and notify a call processing server if a packet loss occurring per unit 
time in the provider's IP network reaches or exceeds a threshold value. 

3. The method of guaranteeing voice quality in an Internet telephony service as set forth in 
Claim 1 or 2, wherein a call processing server that has received a said notification immediately 
performs a procedure to stop the billing of the RTP session in question, or forces 
disconnection of the call that is using the RTP session in question. 

4. The method of guaranteeing voice quality in an Internet telephony service as set forth in 
any one of Claims 1 to 3, wherein said threshold value is either held by a said gateway device 
or is set for each RTP session by an instruction from a call processing server; and, by taking 
into account the codec - and, if possible, the packetizing period - which the RTP session in 
question is using, different values can be used for said threshold according to circumstances. 

5. The method of guaranteeing voice quality in an Internet telephony service as set forth in 
any one of Claims 1 to 4, wherein said threshold value is determined in accordance with codec 
and packetizing period, on the basis of the correlation between packet loss rate and the result 
of objective [1]* measurement of voice quality based on R-value, PSQM, etc. 



* Numbers in square brackets refer to Translator's Notes appended to the translation. 
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6. The method of guaranteeing voice quality in an Internet telephony service as set forth in 
any one of Claims 1 to 5, wherein the point at which said call processing server is notified if 
said packet loss rate reaches or exceeds the threshold value is when, for at least a prescribed 
period of time, no packet of the RTP session in question has been observed after a prescribed 
period of time has passed; and under these circumstances a call processing server forces 
disconnection of the call that is using the RTP session in question. 

7. The method of guaranteeing voice quality in an Internet telephony service as set forth in 
any one of Claims 1 to 6, wherein when said gateway device actually terminates an RTP 
session upon observing said packet loss, it does not only measure the packet loss rate at the IP 
level, but also takes delay jitter into consideration and uses, as an index, the packet loss rate 
when [packets] are actually recovered as voice. [2] 

Detailed Description of the invention 
Technical field of the invention 

[0001] The present invention relates to Internet telephony, and in particular to methods of 
guaranteeing voice quality when time-based billing is carried out in an Internet telephony 
service. 

Prior art 

[0002] Internet telephony enables communication between personal computers in the form of 
IP packets, provided that the PCs in question are connected to microphones and speakers, 
equipped with voice communication software, and connected to the Internet. Internet 
telephony also enables voice communications between a personal computer and a 
conventional telephone by assigning, to a gateway device, the processing by the personal 
computer. An IP network provider provides services for this internet telephony. 

Problems which the invention is intended to solve 

[0003] When an IP network provider offers an Internet telephony service using call processing 
servers owned by the provider in a multi-QoS network likewise owned by the provider, it has 
hitherto been difficult - for reasons (1) to (3) listed below - to guarantee call quality for 
Internet telephony users. 

[0004] (1) Given the nature of the Internet Protocol (IP), the Real-Time Transport Protocol 
(RTP) used for voice communications and the User Datagram Protocol (UDP), there is no 
concept of end-to-end connection or of node-to-node connection in IP networks, and it has not 
been possible to guarantee normal data communications. 
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[0005] (2) For the reason given in item (1) above, if - due to factors internal to a network - 
there has been very significant loss of voice packets from an Internet telephony user who is 
making a call, it is not been possible for a service provider to grasp the situation in real time. 
As a result, when billing on the basis of calling time, billing continues unabated even in 
circumstances where a user cannot carry out voice communication due to some provider-side 
factor. 

[0006] (3) Although conventional IP routers are provided with a function for collecting 
statistical information (packet loss, etc.) at the session level, it has not been possible to support 
this in a Voice over BP (VoIP) service, where the session information to be observed (sent and 
received IP addresses, sent and received port numbers) changes dynamically with each call. 

[0007] (4) The packet loss rate which can be collected by a conventional IP router is collected 
simply as an index of network quality, and cannot be used just as it is as an index of voice 
quality in an Internet telephony service. Moreover, packet loss rate has had to be controlled by 
means of codec and packetizing period, taking into account the effect of voice quality on 
packet loss. [3] 

[0008] It is an object of the present invention to provide a method of guaranteeing voice 
quality whereby an IP network provider offering an Internet telephony service is able to 
provide billing based on guaranteed call quality. 

Means for solving problems 

[0009] To solve the problems described above, the present invention has the following 
features. (1) Packet loss per unit time of each RTP session is observed at a gateway device (a 
router, a remote access server, a trunking gateway, etc.) disposed at the boundary between the 
provider's IP network and a user access network, and if a threshold value (which depends on 
the codec used) held by the gateway device or given by a call processing server is exceeded, 
the call processing server is notified. 

[0010] (2) In the operation described in item (1) above, packet loss rate is measured only for 
packet flows from a gateway to a user. 

[001 1] (3) In the operation described in item (1) above, a call processing server that has been 
notified that a threshold value has been exceeded reacts by either making the call (or the user) 
using the RTP session in question non-billable or forcing disconnection, so that a time-based 
charge is not generated when voice quality has deteriorated. 

[0012] (4) The threshold value mentioned in item (1) above is determined empirically by 
making an objective measurement of voice quality (typified by R-value, PSQM, etc.) and 



4 



NTT Corp. 



XA1910 



correlating the state of deterioration of voice quality due to packet loss with the codec and 
packetizing period. 

[0013] (5) A standard protocol is used to transfer, via the IP network, RTP session information 
(sent and received IP addresses, sent and received port numbers, codec used, threshold values, 
etc.) to gateway devices, and to notify call processing servers when a threshold has been 
exceeded. 

[0014] (6) In the operation described in item (4) above [4], the Internet telephony user 
information which a call processing server holds as its own subscriber information is 
information indicative of which Internet telephony terminal is served by which gateway 
device. On this basis, a call processing server selects the relevant gateway device for each call. 

[0015] (7) The point at which notification is given in item (1) above can be when, for at least a 
prescribed period of time, no packet of the RTP session in question has been observed after a 
prescribed period of time has passed. 

[0016] (8) Call processing servers are provided with a function whereby, when the notification 
described in item (6) above [5] is received, the call processing server forces disconnection of 
the call that is using the RTP session in question. 

[0017] (9) When a gateway device actually terminates an RTP session in the manner of a 
trunking gateway device (a device for implementing voice calls between an IP network and a 
telephone network (PSTN)) upon observing packet loss in item (1) above, instead of merely 
measuring packet loss rate at the IP level, it can also take delay jitter into consideration and 
use, as an index, the packet loss rate when [packets] are actually recovered as voice. [6] 
Accordingly, the method of the present invention has the following distinguishing features. 

[0018] (Claim 1) In the case of a provider such as an ISP or an ASP who arranges, on the 
provider's IP network that uses an Internet protocol, call processing servers such as for 
example SIP proxy servers or gatekeeper servers having a function for converting between the 
user ID and the IP address of a call processing message in an Internet telephony protocol such 
as for example SIP or ITU-T H.323, and who offers an Internet telephony service to users who 
utilize a protocol such as IP or IP over PPP to connect to the provider's IP network: when such 
a provider implements billing by calling time, the provider guarantees a certain minimum 
voice quality for each call, and if call quality falls below standard, the provider stops billing or 
forces disconnection, from the network side, of the call in question. 

[0019] (Claim 2) Gateway devices arranged at connection points in all access modes between 
the provider's IP network and either a user IP network or an IP over PPP terminal, monitor - 
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under the control of a call processing server - packet flows from the provider's IP network to 
users during RTP sessions specified by source and destination IP addresses and source and 
destination port numbers, and notify a call processing server if a packet loss occurring per unit 
time in the provider's IP network reaches or exceeds a threshold value. 

[0020] (Claim 3) A call processing server that has received a notification immediately 
performs a procedure to stop the billing of the RTP session in question, or forces 
disconnection of the call that is using the RTP session in question. 

[0021] (Claim 4) The threshold value is either held by a gateway device or is set for each RTP 
session by an instruction from a call processing server; and, by taking into account the codec - 
and, if possible, the packetizing period - which the RTP session in question is using, different 
values can be used for the threshold according to circumstances. 

[0022] (Claim 5) The threshold value is determined in accordance with codec and packetizing 
period, on the basis of the correlation between packet loss rate and the result of objective 
measurement of voice quality based on R-value , PSQM, etc. 

[0023] (Claim 6) The point at which the call processing server is notified if the packet loss rate 
reaches or exceeds the threshold value is when, for at least a prescribed period of time, no 
packet of the RTP session in question has been observed after a prescribed period of time has 
passed; and under these circumstances a call processing server forces disconnection of the call 
that is using the RTP session in question. 

[0024] (Claim 7) When the gateway device actually terminates an RTP session upon 
observing the packet loss, it does not only measure the packet loss rate at the IP level, but also 
takes delay jitter into consideration and uses, as an index, the packet loss rate when [packets] 
are actually recovered as voice. [7] 

Mode of practising the invention 

[0025] A schematic network configuration is shown in FIG. 1. A service provider such as an 
Internet service provider (ISP) or an application service provider (ASP) arranges call 
processing servers such as SIP proxy servers (SIP) or gatekeeper servers (H.323) in the 
provider's IP network. These call processing servers use the Internet protocol (IP) and have a 
function for converting between the user ID and the IP address of a call processing message in 
an Internet telephony protocol as typified by SIP (Session Initiation Protocol: IETF RFC 
2543) or ITU-T H.323. The service provider thereby provides an Internet telephony service to 
users who utilize a protocol such as IP or IP over PPP to connect to the providers IP network. 

[0026] The function of each part in the configuration depicted in FIG. 1 is as follows. 
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[0027] (1) The modes of access from a personal computer user or a conventional telephone 
user to the provider's IP network are assumed to be connection from an existing telephone 
network, connection by means of a medium-high speed access line such as ADSL or optical 
fibre, or direct accommodation of a user BP network via an Ethernet (registered trademark), a 
dedicated line, etc. 

[0028] (2) Users are connected to the provider's IP network via various kinds of gateway 
device. 

[0029] (3) A voice call between the IP network and a telephone network (PSTN) has the 
following form. Namely, in the case of Internet telephones and telephones, the call processing 
protocol (H.323, SIP, ISUP, etc.) is terminated by call processing servers [8], and the trunking 
gateway devices are controlled from the call processing servers by a standard protocol (here, 
ITU-T H.248/MEGACO is envisaged). Note that an alternative configuration in which the 
trunking gateway devices are integrated with the call processing servers is also feasible. 

[0030] (4) The call processing servers hold, as subscriber information, at least (i) user IDs as 
stipulated by the Internet telephony protocol, and (ii) information relating to the gateway 
devices (IP address, etc.) serving those users. Note that in the case of connection to an existing 
telephone network, call processing servers hold information relating to the trunking gateway 
devices which serve the called telephone numbers (over STM channels). 

[0031] (5) Call processing servers use a standard protocol (here, ITU-T H.248/MEGACO is 
envisaged) to control the gateway devices. 

[0032] (6) Each type of gateway device is provided with a function for measuring packet loss 
per unit time of packet flows coming out into an access network, for RTP sessions stipulated 
by control from a call processing server. 

[0033] (7) The call processing servers are provided with a time-based billing function for 
billing for services. 

[0034] Given the configuration described above, the following processing is performed when 
SIP is used as the Internet telephony protocol and MEGACO is used as the protocol for 
gateway device control from the call processing servers. FIG. 2 and FIG. 3 show the call 
connection sequences involved. 

[0035] FIG. 2 shows the sequence up to connection between users and start of the call. A 
destination user is called (step SI). The call processing servers look up the gateways serving 
the destination and source users (steps S2 and S3). The gateway devices (routers, remote 
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access servers, trunking gateways, etc.) disposed at the boundary between the provider's IP 
network and the user access networks start to observe packet loss rate of the RTP session in 
question and, depending on the codec used, hold within the gateway device [9] (steps S4 and 
S5), and the call starts when the destination goes off-hook (step S6). 

[0036] FIG. 3 shows the sequence when congestion or a fault occurs in the provider's IP 
network, in which cases the following processing is performed. 

[0037] At step SI 1, if the packet loss rate being observed by a gateway device exceeds the 
threshold given by a call processing server, the gateway device notifies the call processing 
server of the deterioration in voice quality by mapping it to a Quality Alert message. 

[0038] Note that it is sufficient to measure packet loss rate in respect of just the packet flow 
from the gateway to the user. Moreover, when a gateway device actually terminates an RTP 
session upon observing packet loss, in the manner of a trunking gateway device (a device for 
implementing voice calls between an IP network and a telephone network (PSTN)), instead of 
merely measuring packet loss rate at the IP level, it can also take delay jitter into consideration 
and use, as an index, the packet loss rate when [packets] are actually recovered as voice. [10] 

[0039] The threshold value is determined empirically by making an objective measurement of 
voice quality (as typified by R-value, PSQM, etc.) and correlating the state of deterioration of 
voice quality due to packet loss rate with the codec and packetizing period. 

[0040] A standard protocol is used to transfer, via the IP network, RTP session information 
(sent and received IP addresses, sent and received port numbers, codec used, threshold values, 
etc.) to gateway devices, and to notify call processing servers when a threshold has been 
exceeded. 

[0041] The point at which notification is given can also be when, for at least a prescribed 
period of time, no packet of the RTP session in question has been observed after a prescribed 
period of time has passed. 

[0042] At step SI 2, a call processing server that has been notified that a threshold value has 
been exceeded reacts by either making the call (or the user) using the RTP session in question 
non-billable or forcing disconnection, so that a time-based charge is not generated when voice 
quality has deteriorated. 

[0043] Note that the Internet telephony user information which a call processing server holds 
as its own subscriber information is information indicative of which Internet telephony 
terminal is served by which gateway device. On this basis, the call processing server selects 
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tic relevant gateway device for each call. Call processing servers can also be provided with a 
function which, when a notification has been received, forces disconnection of the call that is 
using the RTP session in question. 

Benefits of the invention 

[0044] As has been described above, the present invention provides an Internet telephony 
service wherein, when implementing billing by calling time and guaranteeing a certain 
miaimum voice quality for each call, if call quality falls below standard, it is possible to stop 
billing or to force disconnection, from the network side, of the call in question, so that a 
charge does not continue to be generated when voice quality has deteriorated. 

Brief Description of the Drawings 

FIG. 1 schematises the network structure of an Internet telephony service, and depicts a mode 
of practising the present invention. 

FIG. 2 shows the call connection sequence up to connection between users and the start of a 
call in this mode of practising the invention. 

FIG. 3 shows the sequence when congestion or a fault has occurred in the provider's IP 
network in this mode of practising the invention. 
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FIG. 1 
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FIG. 2 
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TRANSLATOR'S NOTES 



1. Sic. 

2. I have added the word in square brackets to make sense of the Japanese, which omits any 
corresponding word. 

3. Sic. Surely this is erroneous for "taking into account the effect of packet loss on voice 
quality". 

4. Sic. I wonder if "item (4)" is erroneous and should have been "item (5)". 

5. Sic. Surely this should be "the notification described in item (7) above". 

6. See Note 2 above. 

7. See Note 2 above. 

8. Sic. 

9. Sic. The Japanese sentence becomes strange at this point. It would have made technical 
sense as follows: "The gateway devices ... start to observe packet loss rate of the RTP 
session in question (steps S4 and S5)". The extra, problematic words, "and, depending on 
the codec used, hold within the gateway device" seem to be a reference to the codec- 
dependent thresholds held in the gateway devices. One way of construing the odd phrase 
is to conclude that crucial words have been erroneously omitted from the Japanese text at 
this point. 

10. See Note 2 above. 
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